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(54) Vertelltes Fahrzeuginformationsverarbeitungs- und Fahrzeugsteuersystem 



(57) Die Erfindung bezieht sich auf ein verteittes 
Fahrzeuginformationsverarbeitungs- und Fahrzeugs- 
teuersystem mit wentgstens einem fahrzeugsertigen, 
erst en Systemtei! und wenigstens einem waiter en, 
zwerten Systemteil zur Ausf Qhrung einer Oder mehrerer 
fahrzeugbezogener Anwendungsfunktionen, wobei die 
Systemteile fiber ein zugehOriges Datenubertragungs- 
netzwerk mrteinander kommunizieren. 

Erfindungsgem&B besrtzen die Systemteile einen 
komponentenbasierten Autbau aus verschiedenen, mit- 
einander kommunizierenden Komponenten zur AusfOh- 
rung verschiedener Funktionen, bei dem jede 
Komponerrte eine Funktionsaufruf-Schnittstelie. Qber 



welche die von der Komponente ausgefuhrte Funktion 
von anderen Komponenten desselben Oder eines ande- 
ren Systemteils aufrufbar ist und eine Konfigurations- 
Schnittstelle aufwerst, Qber die ihre Kbnfiguration varia- 
bel festlegbar ist Hierzu ist eine Konfigurationsmana- 
gereinheit vorgesehen, welche die Komponenten Qber 
diese Schnrttstelle in Abhangigkeit davon korrfiguriert, 
welche anderen Komponenten im System vorhanden 
sind. 

Verwendung z.B. for ein vertelltes Informattonsver- 
arbeitungs- und Steuersystem for Automobile. 
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Beschreibung 

[0001] Die Erfindung bezieht sich auf ein verteiltes 
Fahrzeuginfbrmationsverarbeitungs- und Fahrzeugs- 
teuersystem nach dem Oberbegriff des Anspruchs 1 . 
[0002] Ein solches System beinhaltet wenigstens 
zwei uber ein Datenubertragungsnetzwerk kommuni- 
zierende Systemteile als Netzknoten, von denen minde- 
stens einer fahrzeugseitig angeordnet ist. Das System 
insgesamt dient der Ausfuhrung fahrzeugbezogener 
Anwendungen der verschiedensten, fur Fahrzeuge rele- 
vanten Arten, wie im Zusammenhang mit Benutzer- 
schnittstellen, interner und externer Kommunikation, 
AnwendungsunterstOtzung und mit den eigentlichen 
Anwendungen bzw. Diensten selbst z.B. Ansteuerung 
von Fahrzeugaggregaten, Auswertung von Fahrzeug- 
sensorinfbrmationen und allgemeine Dienste, wie Navi- 
gation, Diagnose, Diebstahlschutz und Datenaustausch 
mit entfernten Netzwerkknoten z.B. uber das Internet. 
[0003] Moderne Fahrzeugsysteme zeichnen sich 
durch einen immer grCSer werdenden Datenverarbei- 
tungsanteil, d.h. eine zunehmende Bedeutung von Tele- 
matikanwendungen aus. So verlangen z.B. Pannen- 
hilfedienste und dynamische Navigationsdienste 
ebenso wie Internet-basierte Anwendungen die Reali- 
sierung verteilter Systeme. bei denen das Fahrzeug 
nicht mehr als isoliertes Einzelsystem. sondem als akti- 
ver Knoten in einem verteilten Datenkommunikations- 
system mit vorzugsweise weltweiter Reichweite 
betrachtet wird. Fahrzeugseitig implement! erte System- 
anwendungen wenden dabei im allgemeinen sowohl Cli- 
ent- als auch Serverfunktionen Obemehmen. 
[0004] Bei einem in der Offenlegungsschrift DE 1 96 
25 002 A1 offenbarten Fahrzeugkommunikationssy- 
stem ist bereits eine Schichtung von fur ein Fartrzeugsy- 35 
stem notwendigen Funktionalitaten vorgeschlagen 
worden, die unter Einsatz einer adaptiven Applikations- 
steuerung eine gewisse Nferiabilitat in der Zuordnung 
der Anwendungen zu verschiedenen Schnittstellen und 
fahrzeugseitigen Gerateeinheiten erlaubt. 40 
[0005] Auf dem Gebiet der allgemeinen Datenver- 
arbeitung ist in jQngerer Zeit alternativ zu zentralen 
Systemarchitekturen ein komponerttenbasierter 
Systemaufbau vorgeschlagen worden, siehe beispiels- 
weise den Zeitschriftenaufsatz D. Kiely, "Are Compon- as 
ents - The Future of Software?", IEEE Computer 
Magazine, Serte 10. Februar 1998. Dabei wird die vom 
Gesamtsystem zu erbringende Funktion mittels Dekom- 
position in einzelne Funktionskomponenten zerlegt, die 
dann durch geeignete Verknupfung und Kommunikation so 
untereinander die gewunschte Gesamtfunktion erbrin- 
gen. Die Aufteilung in Komponenten vereinfecht dabei 
zum einen die Wiederverwendung derselben und das 
Aufbauen tomplexer Systeme aus diesen Korrponen- 
ten und zum anderen das Erstellen von robusten Kom- 55 
ponenten selbst. da diese nur mit einem begrenzten 
und Oberschaubaren Funktionsumfang ausgestattet 
werden mOssen. Charakteristisch for die Kbrrponenten 



ist ihre nach auBen gleichartige Architektur, die es auf 
einfeche Weise ermdglicht. sie untereinander zu ver- 
knupfen, wobei die von einer Komponente erbrachte 
Funktion zunachst unabhangig von dieser Architektur 
5 gesehen werden kann. 

[0006] Das explosive Wachstum des Internet bzw. 
des World-Wide-Webs hat dazu gefOhrt, daB verteilte 
Systeme zunehmende Bedeutung gewinnen. Urn die 
Realisierung sdcher Systeme zu erleichtem und urn 
10 komponentenbasierte System umsetzen zu k6nnen, 
haben sich immer mehr verteilte Objektmodelle eta- 
Wiert. Die SystementwicWer stutzen sich dabei immer 
starker auch auf Internet-orientierte LOsungen fur diese 
Objektmodelle und realisieren sie z.B. mit Java RMI 
is bzw. "Java Beans", siehe entsprechende Internet-lnfor- 
mationen der Firma Sun Microsystems, mit DOOM von 
Microsoft, siehe die Ver6ffentfichungen T. Albertson, 
"Best Practices in Distributed Object Application 
Development: RMI, CORBA und DOOM, Februar 1998, 
so Internet-Seite "http://developer.com/ news/techfocus/ 
02239_distl.htm" und RE. Chung et ah, "DCOM 
and CORBA Side by Side, Step by Step, and layer 
by Layer, September 1997. Internet-Seite 
"httpy/wvsw.cs.wi^ 
25 oder auf Basis von CORBA, siehe auch A. Vogel, K. 
Duddy, "Java Programming with CORBA". John Wiley & 
Sons. 1997. 

[0007] Wie aus der genannten Literatur deutlich 
wird, ist der Trend hin zu objektorientierten Korrponen- 
30 tenmodellen durch die fblgenden Vorteile erWaibar: 
Erstens durch die Wiederverwendung existierender 
Aigorrthmen bzw. Software und damit verbunden durch 
die MOglichkeit zum "r^>id prototyping" von Anwendun- 
gen durch "plug-and-playMmeraktion der Komponen- 
ten; zweitens durch voneinander unabhangige 
EntwicWung und Implementierung von Kbrrponenten; 
drittens durch effiziente Code-Wartung inWusive der 
systematische Verteilung von Aktuatisierungen bzw. 
"Updates"; und viertens durch "Ughtweight"- und "Thin 
dients'-Reaiisierungen, die mit irtfrastrukturbasierten 
Systemen kommunizieren, die dort an verschiedenen 
Stellen lokalisiert sein kOnnen. Eine der charakterisie- 
renden Eigenschaften von Komponenten besteht darin, 
daB sie einer einheitlichen Architekturvorgabe fblgen, 
die es erleichtert. sie zu einem Gesamtsystem zusam- 
menzufugen. Dabei hat diese Architektur primar nichts 
mit der eigentlichen Funktion der Komponente zu tun. 
Sie legt vielmehr test, wie die Komponenten mrteinan- 
der agieren, aber nicht worflber sie sich "unterhalten M . 
Diese Charakterisierung gilt unabhangig davon, ob die 
konkrete Komponente in Software Oder Hardware reali- 
siertist 

[0008] Der genannte Trend zu Komponentenmodel- 
len auBert sich in der zunehmenden Bedeutung von 
Technologies die verteilte Komponerrtensysteme 
unterstotzen, wie "Java Remote Method Invocation 
(RMI)" als Basis fOr die JavaBeans-Kbmponenten, 
"Common Object Request Broker Architecture 
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(CORBA)" und "Distributed Component Object Model 
(DCOM)" von Microsoft zur Realisierung von ActiveX. 
Alle diese Modelle folgen dem Client/Server-Ansatz. 
Bisherige Fahrzeuge sind, wenn sie am Ende der Pro- 
duktion dem Kunden ubergeben werden, in ihrer Funk- 5 
tionalitdt bezuglich ausfuhrbarer Dienste relativ stark 
fixiert. In Zukunft werden im Fahrzeug jedoch immer 
mehr Dienste zum Einsatz kommen, wie sie auch in der 
Buro- und Geschaftswelt Verwendung find en, die im 
Moment der Fertigstellung des Fahrzeugs aber haufig to 
noch gar nicht existieren. Der Kunde wird daher haufig 
den Wunsch haben, zur Lebenszeit des Fahrzeugs die- 
ses mit entsprechenden neuen Diensten nachrusten zu 
kdnnen. Erfolgt die Nachrustung durch zusdtziich in das 
Fahrzeug eingespielte Software, so reicht hierfur 75 
irgendwann der dafur notwendige Speicherplatz im 
Fahrzeug nicht mehr aus. Eine Nachrustung mit zusatz- 
licher Hardware ist hingegen vergleichsweise kostenin- 
tensiv und fehleranfallig und verlangt in den meisten 
Fallen einen Werkstattauferrthart Es besteht daher 2 o 
Bedarf an Systemen, die relativ einfach mit zusatzlichen 
Funktionen nachrustbar sind. die beispielsweise als 
Software-Bausteine realisiert sind. so daB keine Hard- 
ware-Modrfikation ndtig ist. Des weiteren ist es wun- 
schenswert. das System durch dynamische 25 
Verlagerung vorzugsweise der Software- Baust eine zur 
Laufzeit des Fahrzeugs von Oder zum fahrzeugsertigen 
Systemteil optimal an sich andernde Anforderungen 
bzw. Bedingungen anpassen zu kOnnen. Dies trrfft bei- 
spielsweise fur wechselnde Bedingungen bei der draht- 30 
losen Kommunikation zu. Ist nur eine schmalbandige 
Kommunikationsstrecke vorhanden, sollte so wenig wie 
mOglich Kommunikation betrieben und so viel wie mdg- 
lich notwendige Software im Fahrzeug untergebracht 
werden. Ist hingegen eine Kommunikationsverbindung 35 
mit hoher Ubertragungskapazitat vorhanden, kann 
gewisse Bearbeitungssoftware gQnstiger in einem fahr- 
zeugexternen Systemteil untergebracht sein, um die 
dort meist grCBeren Rechenkapazitaten ausnutzen zu 
kOnnen. 40 
[0009] Der Erfindung fiegt daher als technisches 
Problem die Bereitstellung eines Fahrzeuginformations- 
verarbeitungs- und Fahrzeugsteuersystems der ein- 
gangs genannten Art zugrunde, das in seiner Struktur 
zur Erfullung unterschied licher fahrzeugbezogener -45 
Anwendungen vergleichsweise flexibel so aufgebaut ist, 
daB ein Nachrusten mit weiteren Funktionen mit relativ 
geringem Aufwand mOglich ist und die Voraussetzung 
geschaffen ist, die Ausfuhrung der geforderten Anwen- 
dungen dynamisch und flexibel zwischen den System- so 
teilen variabe) aufteilen zu kdnnen und das Fahrzeug 
als aktiven Netzknoten in ein gegebenerrfalte weltum- 
spannendes Datennetzwerk integrieren zu kGnnen. 
[0010] Die Erfindung IGst dieses Problem durch die 
Bereitstellung eines Fahrzeuginformationsverarbei- 55 
tungs- und Fahrzeugsteuersystems mit den Merkmalen 
des Anspruchs 1. Die Systemteile dieses verteirten, 
fahrzeugbezogenen Systems haben charakteristi- 



scherweise einen komponentenbasierten Aufbau aus 
verschiedenen, miteinander kommunizierenden Kom- 
ponenten zur Ausfuhrung der verschiedenen 
gewunschten Anwendungsfunktionen. Jede dieser so 
definierten Komponenten, die vorzugsweise in Software 
realisiert sind, besitzt einerseits eine Funktionsaufruf- 
Schnittstelle, uber welche die von der Komponente aus- 
gefuhrte Funktion von alien aktiven Knoten des Netz- 
werks abrufbar ist, und eine Konfigurations- 
Schnittstelle, Qber die ihre Konf iguration variabe! mittels 
einer zu cfiesem Zweck vorgesehenen Konfigurations- 
managereinheit festlegbar ist. Dazu erhatt die Konfigu- 
rationsmanagereinheit Kenntnis uber die im System 
vorhanden en Komponenten und konf iguriert die jewei- 
lige Komponente uber der en Konf igurations- Sen nitt- 
stelle in Abhangigkert davon, welche anderen 
Komponenten vorhanden sind. Mit dieser Konfigurati- 
onsmanagereinheit kann folglich eine Komponente, die 
neu in einen Systemteil etngebracht wird, sei es durch 
Nachrustung des Systems mit derselben oder durch 
Verlagerung aus einem anderen Systemteil, so "hinein- 
konfigurierT werden, daB sie optimal mit den ubrigen 
vorhandenen Komponenten kommunizieren kann. Die 
Einpassung der neuen Komponente in den betreffen- 
den Systemteil kann gegebenenfalls zusdtziich eine 
Modifizierung der Konf iguration einer oder mehrerer der 
bererts zuvor vorhandenen Komponenten beinhalten. 
Durch diesen Aufbau IdBt sich das fahrzeugbezogene 
System mit einer allgemeinen Datenverbeitungs-Platt- 
form ausrusten, die ein flexibles Nachladen werterer, 
ausfuhrbarer fahrzeugbezogener Anwendungen zu 
jedem Zeitpunkt wahrend der Lebensdauer des Fahr- 
zeugs und ein kostenoptimiertes Reagieren von Dienst- 
ausfuhrungen auf variable externe Bedingungen 
ermoglicht 

[001 1 ] Bei einem nach Anspruch 2 weitergebildeten 
System ist fur den jeweiligen Systemteil ein Komponen- 
tenlader vorgesehen, in der allgemeinen EDV auch als 
"Badewanne" bezeichnet, der die jeweiligen Kompo- 
nenten aufnimmt und uber den diese mit einem 
Betriebssystem des Systemteils kommunizieren, an 
das andererserts je nach Systemteil verschiedene 
externe Qerateeinheiten angekoppelt sind. 
[0012] Bei einer Werterbiidung des Systems nach 
Anspruch 3 ist eine funktionsorientierte Hierarchie der 
Komponenten in fahrzeugbauteilbezogene Komponen- 
ten oder "lnterface w -Komponenten. die sich eng an den 
vorhandenen Hardware-Fahrzeuggerateeinheiten ori- 
errtieren und zum Beispiel den Zugrrff auf Hardware- 
Schnittstellen fur Kommunikationsgerdte oder die 
Anzeige- und KontrollgerSte einer Benutzerschnittstelle 
realisieren, in Aggregations- Komponenten, die Dienste 
anbieten, welche Roh information en aus den fahrzeug - 
bauteilbezogenen Komponenten aggregieren. und in 
ubergeordnete Anwendungs-Komponenten vorgese- 
hen, welche die eigentiichen Dienste reprasentieren 
und die sowohl auf die Aggregations-Komponenten als 
einer Zwischenschicht als auch auf die fahrzeugbauteil- 
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bezogenen bzw. Benutzerschnittstellen-Kbnrponenten 
Zugriff haben. 

[001 3] Bei einem nach Anspruch 4 weitergebildelen 
System sind Mittel zum dynamischen Verfagern einer 
Oder mehrerer der Komponenten zwischen den beteilig- 
■ : ; ten Systemtellen wahrend der Systemlaufzeit und damit 
insbesondere zu beliebigen Zerten wahrend der gesam- 
ten Lebenszeit des Fahrzeugs vorgesehen. Diese Kom- 
ponentenverlagerungsmittel nutzen die Tatsache, daft 
_die Komponenten mit einer Konfigurations-Schnittstelle 
Versehen sind und uber diese variabel in eine neue 
Kbmponentenumgebung eines anderen Systemteils 
"hineinkonfiguiierbar" sind. Dadurch kann eine jeweilige 
Komponente beispielsweise abhangig von sich andern- 
den externen Bedingungen, wie der verfugbaren uber- 
tragungskapazitat der Kbmmunikationsstrecke des 
Netzwerks, fQr gewisse Zerten in einem und fQr andere 
Zeiten in einem anderen Systemteil plaziert werden. 
FOr eine solche Verlagerung eignen sich insbesondere 
diejenigen Komponenten, die nicht eng mit fehrzeugsei- 
tigen Hardware-GerSteeinheiten zusammenhangen. 
[0014] Bei einem nach Anspruch 5 weitergebildeten 
System erfolgt die Kommunikation zwischen anwen- 
dungsbezogenen Komponenten direkt, wobei dann die 
Kqnponente die Schnittstellen derjenigen Komponen- 
ten kennen muB. die sie verwendet Oder uber eine 
jeweilige. gemeinsam genutzte Datenhaltungs-Kbrrpo- 
nente, in welche die beteiligten Anwendungs-Korrpo- 
nenten neue Informationen einschreiben und dort neu 
eingeschriebene Informationen von anderen beteiligten 
Komponenten auslesen kOnnen. In diesem Fall brau- 
chen die Anwendungs-Kbmponenten die Schnittstellen 
der anderen Komponenten nicht zu kennen, es muB 
jedoch vereinbart werden, welche Inhalte in die Daten- 
haKungs-Komponente geschrieben werden. 
[0015] Vorteilhafte AusfOhrungsformen der Erfin- 
dung sind in den Zeichnungen dargestellt und werden 
nachfoigend beschrieben. Hierbei zeigen: 

F| 9- 1 eine schematische Darstellung eines 

verteiften Fahrzeugirrformationsver- 
arbeitungs- und Fahrzeugsteuersy- 
stems mit fahrzeugseitigem und 
fahrzeugexternen, miteinander ver- 
netzten Systemtellen, 

^9-2 ein schematisches Blockdiagramm 

der Umgebung einer Port-Manager- 
Komponente im fahrzeugseitigen 
Systemteil von Rg. 1, 

Rg. 3 ein schematisches Blockdiagramm 

der Umgebung einer Location-Mana- 
ger-Komponente im System von Rg. 

F| 9- 4 ein schematisches Blockcfiagramm 

der Umgebung einer Prfisentations- 



Manager-Komponente im System 
von Fig. 1, 

Fi 9- 5 ein schematisches Blockdiagramm 

der prinzipiellen, komponentenba- 
sierten Architektur des Systems von 
Fig. 1, 

Fi 9- 6 ein schematisches Blockdiagramm 

10 der funktionsorientierten hierarchi- 

schen Aufteilung der Komponenten 
im System von Fig. 1, 

Fj 9- 7 ein schematisches Blockdiagramm 

15 zur Veranschaulichung der dynami- 

schen Verlagerung einer Kon^po- 
nerrte zwischen Systemteilen von 
Fig. 1, 

20 Fig. 8a und 8b schematische Blockdiagramme zur 
Veranschaulichung der Korrponen- 
tenverlagerung am Beispiel einer 
Sprachbedien-Anwendung, 

25 Fj 9 9 ein schematisches Blockdiagramm 

eines Navigations-Teilsystems des 
Systems von Rg. 1 auf Dienste- 
schnittstellen-Basis. 

30 Fig. 10 ein schematisches Blockdiagramm 

zur Veranschaulichung einer Dienst- 
interaktion im System von Rg. 1 Qber 
eine Datenhaltungs -Komponente 
und 

35 

Fi 9- 11 ein schematisches Blockdiagramm 

zur Veranschaulichung des Aufrufs 
einer Komponentenmethode. 

40 [0016] Fig. 1 zeigt schematisch ein verteiltes Fahr- 
zeuginformationsverarbeitungs- und Fahrzeugsteuersy- 
stem, das eine Mehrzahl von rdumlich getrennten 
Systemteilen 1a, 2a 3a urrtfaBt, die aktive Netzknoten 
eines DatenObertragungsnetzwerks 4, wie z.B. das 
45 Internet, bilden und uber dieses miteinander kommuni- 
zieren. Ein erster Systemteil befindet sich im Fahrzeug 
1 sebst das einen "Mobile-Host" des Netzwerks 4 dar- 
stellt. Ein zweiter, stationdrer Systemtefl 2a b^indet 
sich in einem Service-Provider 2, wahrend sich ein drit- 
ter Systemteil 3a in einem Hochleistungs-Service-Cen- 
ter 3 befindet. Weitere Fahrzeuge k6nnen in gleicher 
Weise aktive Netzknoten bilden. die auf Dienste des 
Service-Providers 2 und des Hochleistungs-Service- 
Centere 3 zugreifen kOnnen. wobei in nicht gezeigter 
auch jeweils eine Mehrzahl der beiden letztgenannten 
Dienstanbieter im Datennetz 4 vorhanden sein kann. 
Diese fahrzeugexternen Dienstanbieter 2, 3 dienen Qbli- 
cherweise vor allem dazu, Dienste fOr das Fahrzeug 1 
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auszufuhren, die eine relativ hohe Rechenkapazitat 
erfdrdern, wie sie im Fahrzeug 1 nicht ohne weiteres 
verfugbar ist, z.B. aufwendige Navigationsdienste wie 
verkehrslageabhangige Routenfindung. Das Fahrzeug 
1 hat ebenso wie die stationaren Dienstanbieter 2, 3 
eine Netzwerkidentitat, mit dem es im Netzwerk 4 
bekannt ist. in den FunktionsblOcken der drei gezeigten 
Netzknoten 1 , 2, 3 ist schematisch angedeutet, daB der 
dort jeweils implementierte Systemteil 1a, 2a, 3a einen 
komponentenbasierten Aufbau besrtzt, worauf unten 
nSher eingegangen wird. Fur den vorliegenden Anwen- 
dungsfall von Fahrzeugsystemen erscheint hierfur von 
den oben genannten drei herkommlichen Technologien, 
die verteirte Komponentensysteme unterstutzen, nam- 
lich RMI, CORBA und DOOM, die Java-RMI Technolo- 
gie besonders geeignet, da sie plattformunabhangig 
und mit relativ geringem Aufwand handhabbar ist. 
[0017] Die Komponenten, aus denen die System- 
teile 1, 2. 3 und damit das System insgesamt aulgebaut 
ist, beinhalten jeweils zwei Schnrttstellen, und zwar eine 
Funktionsaufruf- Oder Remote-Schnrttstelle, uber wel- 
che die eigentliche Funktion der betreffenden Kompo- 
nente, d.h. ihr Dienst, von einer anderen Komponente 
desselben Systemteils oder auch von einem entfernten 
Netzknoten aus aufgerufen werden kann, und eine Kon- 
figurations-Schnittstelle. die zur variablen, situationsan- 
« gepaSten Konfigurierung der Komponente cfient. Uber 
diese Konfigurations-Schnittstelle kann die Kompo- 
nente variabel in verschiedene Umgebungen des 
Systems "hineinkonfiguriert" werden, und vorhandene 
Komponenten konnen uber diese Schnittstelle von der 
neu plazierten Komponente in Kenntnis gesetzt werden. 
Dies ermogltcht ein eirrfaches Einbringen und Verlagern 
einer Komponente auch nach der Systemgenerierung 
zur Systemlaufzeit, selbst bei gednderten Randbedin- 
gungen des Systems. In diesem Fall mussen die neu 
eingebrachten und unter Umstanden auch die schon 
bisher vorhandenen Komponenten des Systems aufein- 
ander angepaBt werden. Dies kann z.B. bedeuten, da 6 
die Adressen der Komponenten untereinander bekannt- 
gemacht werden mussen, wozu die Komponenten eine 
eigene "Home-Page" anbieten, Qber welche die not- 
wendigen Modrfikationen vorgenommen werden kon- 
nen. Vorliegend ist zur Durchfuhrung dieser 
Konfigurationsaufgabe eine spezielle Konfigurations- 
managereinhert vorgesehen. Diese weiB. welche Kom- 
ponenten momentan im System vorhanden sind und 
hat uber die Konfigurations-Schnrttstelle Zugrrff auf die 
einzelnen Komponenten zur Modifikation ihrer Korrfigu- 
ration. 

[0018] Der Systemteil 2a des Service-Providers 2 
enth&tt primdr Anwendungs-Komponenten zur Ausfuh- 
rung von Diensten fahrzeugbezogener Funktionalitat. 
wdhrend der Systemteil 3a im Hochleistungs-Service- 
Center 3 primar Anwendungs-Support -Komponenten 
enthait, die Hochleistungsrechenkapazitaten benotigen. 
Im fahrzeugsertigen Systemteil 1a sind neben Anwen- 
dungs-Komponenten, welche die eigerrtlichen Dienst- 



anwendungen reprdsentieren, vor allem auch 
"geratenahe" Komponenten vorhanden, die zur Steue- 
rung von im Fahrzeug 1 verbauten Hardware-Gerate- 
einheiten dienen, wie z.B. eine PrSsentations-Manager- 

5 Komponente 19. die auf eine optische Anzeige 24 und 
einen Lautsprecher 26 zugrerft. ZusStzlich dienen 
Kommunikations-Manager-Komponenten der Abwick- 
lung von Datenkommunikationsvorgangen zwischen 
den Systemteilen 1a, 2a, 3a uber das Netzwerk 4. Der 

w Gesamtheit der Komponenten des jeweiligen System- 
teils 1a, 2a, 3a ist ein zugehoriger Komponenten-Lader 
("Badewanne") oder Komponenten -Server 1b, 2b, 3b 
zugeordnet. Als ein solcher Komponerrten-Lader 
eignet sich z.B. der in der Programmiersprache Java 

is implementierte ChaiServer der Firma Hewlett-Packard, 
der das Laden der Komponenten sowie das Routing 
von Methodenaufrufen an die entsprechenden Kom- 
ponenten unterstutzt; fur weitere Details siehe die 
Firmeninforrnationen Hewlett-Packard "HP ChaiSer- 

20 ver: An Overview" auf der Internet-Seite 
w httpy/www.chai.hp.com/emso/pdf/chaiseiverwp.pdf" 
und "HP Application Server" auf Internet-Seite 
"http y/www. hpconn ect. oorrVembeddeoVvrn/sweb. htm" . 
[0019] In den Fig. 2 bis 4 sind drei Beispiele fur 

25 Komponenten des Fahrzeuginformationsverarbeitungs 
- und Fahrzeugsteuersystems veranschaulicht Rg. 2 
zeigt eine Part-Manager-Kbrrponente 5 in ihrer System- 
umgebung, z.B. innerhalb des im Fahrzeug 1 befindli- 
chen Systemteils. Die Part-Manager-Komponente 5 

30 gehort zu einer Gruppe von hardwareunterstutzenden 
Irrterface-Komponenten, die eng im Zusammenhang mit 
fahrzeugsertigen Hardware-Gerateeinheiten stehende 
Funktionen ausfuhren, z.B. Treiberfunktionen. Die Part- 
Manager-Komponente 5 ermdglicht den Zugrrff auf eine 

35 serielle Schnittstelle 6 der Maschine, hier dem Fahr- 
zeug 1. auf der sie abiauft. Dabei werden die Zugriffs- 
methoden so zur Verfugung gestellt, da 3 auf sie von 
jeder berechtigten Remote- Komponente zugegriffen 
werden kann. Die Part-Manager-Komponente 5 kennt 

40 hierzu die Schnrttstellen des Systems und verwaltet 
unter anderem die Zuordnung der Schnrttstellen und 
der angeschlossenen Gerate. Sie ist auBerdem verant- 
wortiich fur die Regelung von konkurrierenden Aufrufen 
anderer Komponenten auf die Ports. Uber ihre Remote- 

45 Schnittstelle 5a erlaubt die Part-Manager-Komponente 
5 einen Zugrrff auf die Schnrttstellen des Systems von 
jeder beliebigen Stelie im Netzwerk, wie z.B. von zwei 
explizit gezeigten Anwendungen 7a, 7b. Zusatzlich ist 
die Konfigurations-Schnittstelle 5a der Part-Manager- 

so Komponente 5 schematisch gezeigt. Die Part-Manager- 
Komponente 5 hat keine Information uber den semanti- 
schen Inhalt der Irrformationen. die uber sie abgerufen 
oder geschrieben wird. tn der gewdhften Java- Imp! e- 
mentierung ist daher die Java-Virtual-Machine (JVM) 8 

55 dutch zusatzlich gebildete Klassen 9. d.h. "Port-Clas- 
ses", in die Lage versetzt, einen physikalischen Zugrrff 
auf die serielle Schnittstelle 6 zu erlauben. 
[0020] Die in Fig. 3 in ihrer Einbettung in die archi- 
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tektonische Systemumgebung gezeigte Location- 
Manager-Komponente Oder Positions-Manager-Kom- 
ponerrte 10 hat die Funktion, Positionsinfbrmaton zu 
sammeln und diese dann aggregiert als Ortsinformati- 
onsdienst anzubieten. Mdgliche Informationsquellen 5 
sind z.B. ein GPS-Empf anger 1 1 und Koppelnavigati- 
onssensoren 12, 13, wie KompaB und Radumdre- 
hungszahler. Die Location-Manager-Komponente 10 
greift dazu auf entsprechende Interface-Komponenten 
zu, wie den oben erwahnten Port-Manager 5 und eine 10 
CAN-Manager-Komponente 14, die ihrerseits Ober die 
JVM/Betriebssystems-Schicht 15 auf eine CAN-Schnitt- 
stelle 16 zugrerft. 

[0021 ] Mit einem AusJagerungspfeil 1 7 ist eine Aus- 
lagerungsmGglichkeit veranschaulicnt, wonach die 75 
Location-Manager-Komponente 10 nicht zwingend auf 
derselben Maschine, z.B. dem Fahrzeug 1, laufen muB 
wie die Interface-Komponerrten 5, 14, auf die sie 
zugreift, sondern eine externe, ausgelagerte Kompo- 
* nente 10' bilden kann, die sich in einem anderen 20 
Systemteil befindet. Ob eine solche Auslagerung 
zweckmaBig ist, hangt von den jeweils momentanen 
Randbedingungen, insbesondere dem Aufwand und 
den Kosten fur die Datenkommunikation zwischen den 
Systemteilen ab. Im ubrigen weist auch die Positions- 25 
Manager-Komponente 10 wie alle Komponenten des 
erfindungsgemaBen Systems wiederum eine Remote- 
Schntttstelle 10a zur Kommunikation mit anderen Dien- 
sten 18a. 18b und eine Konfigurations-Schnittstelle 10b 
auf. 30 
[0022] Fig. 4 zeigt wiederum eingebettet in ihre 
Systemumgebung eine Prasentations-Manager-Kom- 
ponente 18 mit Remote-Schnrttstelle 18a zum Funkti- 
onsabruf durch andere Anwendungen 20a, 20b und 
Konfigurations-Schnittstelle 19b. Die Presentations- 35 
Manager-Komponente 19 ist fOr die Wiedergabe von 
Information der Anwendungen 20a, 20b zustandig und 
gibt die Information in Abhangigkeit von austauschba- 
ren Strategien an den Benutzer wetter. Diese Strategien 
konnen beispielsweise beinhalten, da6 wdhrend der 40 
Fahrt Information nur Ober Sprachausgabe stattfindet 
und eine optische Anzeige (Display) nur im Stand akti- 
viert wird. Durch solche Strategien lassen sich erforder- 
liche Sicherheitsvorkehrungen in das System 
einbringen, damrt der oder die Fahrzeuginsassen nicht 45 
von ihrer eigentlichen Aufgabe abgelenkt werden. Der 
Prasentations-Manager hat zur Erfullung seiner Auf- 
gabe Ober jeweilige Schnittstellen-Manager-Komponen- 
ten 21, 22 und das Betriebssystem 15 nebst 
entsprechenden Schnittstellen Zugriff auf Benutzer- so 
schnittstellen-Komponenten des Fahrzeugs, wie "Text- 
to-Speech"-, "Speech-to-Text"-Gerate 23, optische 
Anzeigen 24 und "Touch-Screen"- bzw. "Pointing"- 
Gerate. Die Prasentations-Manager-Komponente 19 
kooperiert eng mit dem Konf igurationsmanagement des 55 
Systems, da sie InfbrmationendarQber benOtigt, welche 
Aus- und Eingabegerate im Fahrzeug vorhanden sind. 
AuBerdem ist sie in der Lage. konkurrierende Ausgabe- 



anforderungen verschiedener Anwendungen geeignet 
aufzulOsen, vergleichbar einem "Window-Manager". 
[0023] Wie gesagt, ist die Architektur des verteilten 
Fahrzeuginformationsverarbeitungs- und Fahrzeugs- 
teuersystems vollstandig aus Komponenten aufgebaut. 
wobei in den Figuren die Komponenten zur einfacheren 
Identif izierung jeweils mit einem kleinen Dreieck in der 
oberen linken Ecke ihres Funklionsblocks markiert sind. 
Fig. 5 zeigt die prinzipielle Architektur des Systems, 
bestehend aus einer Anzahl n von Komponenten 
K 1t ...K n , denen ein Komponenten-Server KS zugeord- 
net ist und die uber das jeweilige Betriebssystem BS auf 
eine Anzahl m externer Gerate G 1( ...G m Zugriff haben. 
Aus dieser Software-Sichtweise besteht das System 
folglich aus einer Menge von miteinander kommunizie- 
renden Komponenten K 1( ...K n , wobei es auf dieser 
Ebene keine Hierarchien zwischen den einzelnen Kom- 
ponenten ^....K,, gibt. 

[0024] Die Kommunikation zwischen den System- 
objekten basiert auf herkCmmlichen Vorgehensweisen, 
wie "Remote-Procedure-Call" (RPC) bzw. dessen Java- 
Version, der "Remote-Method-Invocation" (RMI). 
Methoden einer Kbmponente, die von einer anderen 
Komponente aufgerufen werden sollen, werden in einer 
Interface-Datei beschrieben, vergleichbar mit der "Inter- 
face-Description-Language" (IDL) von CORBA. Aus 
dieser Datei werden dann die nOtigen "Stubs" generiert. 
die zu einer Kbmponente hinzugebunden werden. Zur 
Adressierung der Methoden wird der "Unifoim- 
Resource-Ljocater" (URL) verwendet, mit dem diejenige 
Machine adressiert wird, auf der die angesprochene 
Komponente lauft, und auf dem des weiteren die Kbm- 
ponente selbst und die gewunschte Methode mit Argu- 
menten angegeben werden kann. Durch die UAL- 
Adressierung wind Ortstransparenz, d.h. Positionie- 
rungsunabhangigkeit der Komponenten, erreicht, da die 
AuflOsung der Maschinenadresse unabhangig von der 
Qient-lnstanz erfolgt, z.B. Ober einen "Domain-Name- 
Service" (DNS). 

[0025] Fig. 6 zeigt eine funktionsoriente Anordnung 
der Komponenten des Systems. In dieser Darstellung 
ist eine dreistufige Hierarchie der Komponenten vorge- 
sehen, bei der eine oberste Schicht aus eigentlichen 
Anwendungen, eine mittlere Schicht aus Anwendungs- 
unterstutzungsfunktionen und eine untere Schicht aus 
Schnittstellensteuerungsfunktionen besteht. Die Kom- 
ponenten der obersten Schicht bilden die eigentlichen 
Anwendungen oder Dienste, d.h. Anwendungs-Kompo- 

nenten AK 1f AK 2 , AK 3 Beispielhaft sind ein Nach- 

richtenvorleser und eine Navigationskomponente 
gezeigt. Zur Erfullung ihrer Aufgaben greifen die 
Anwendungs-Kbmponenten AK 1( AK 2 , ... auf die mitt- 
lere Schicht von anwendungsunterstotzenden Kompo- 
nenten UK 1t UK 2 . UK 3 , ... zu, die auch als 
Aggregations-Komponenten bezeichnet werden kOn- 
nen, da sie Rohdaten, die aus verschiedenen Quellen 
im Fahrzeug und aus der fahrzeugexternen Inf rastruktur 
des Netzes kommen kOnnen, geeignet aggregieren. 
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Beispiele fur solche Anwendungsunterstutzungskom- 
ponenten sind die oben eriauterten Location-Manager- 
und Prasentations-Manager-Komponenten sowie die 
Kommunikatons -Manager-Komponente. Diese anwen- 
dungsunterstutzenden Komponerrten UK^ t UK 2 , UK 3 , ... 
greifen ihrerseits auf die Interface- Komponerrten IK 1( 
IK 2 , IK 3 . ... der unteren Schicht zu, die eng an fahrzeug- 
seitige Hardware-Gerateeinheiten angebundene Kom- 
ponenten darstellen, wie der oben eriauterte (serielle) 
Port-Manager, eine CAN-Manager- und eine Anzeige- 
Manager-Komponente. 

[0026] Allen Komponenten ist der Komponerrten- 
Lader KL zugeordnet, und die Komrnunikation mit exter- 
nen Geraten, z.B. einer optischen Anzeige 24, einer 
Audio-Schnittstelle 27, Modems 28, einem GPS-Emp- 
fanger 29 und einem DVD 30 erfolgt uber die JVM/ 
Betriebssystem-Schicht 15. Auf diese Weise unterstutzt 
das System externe Gerate, die der Benutzerschnitt- 
stelle zuzuordnen sind, aber auch Gerate, die der 
Benutzer neu in das System einbringt. Wenn fur nach- 
gebrachte externe Gerate keine Interface- Komponen- 
ten vorhanden sind, sind sie nachtraglich zu laden. Den 
erwahnten, funktionsorientiert in drei Schichten geglie- 
derten Komponenten ist gemeinsam eine Konfigurati- 
ons-Manager-Komponente KM zugeordnet, mit deren 
Hilfe die Komponerrten dynamisch zwischen den ver- 
schiedenen Systemteilen des Systems verlagert wer- 
den kdnnen. 

[0027] Ein weiterer Anwendungsfall ist das Nachla- 
den von Komponenten insbesondere der obersten 
Schicht, d.h. von Anwendungs-Komponenten. Das mit 
Hilfe der vorliegenden Plattform mOgtiche Nachladen 
solcher Anwendungs-Komponenten behebt die Schwie- 
rigkeit, daBfur Fahrzeugsysteme im Moment ihrer Pro- 
jektierung haufig nicht genau bekannt ist, welche 
Dienstefurden Kunden uber die gesamte Lebensdauer 
des Fahrzeugs hinweg von Interesse sein werden. Ins- 
besondere kommen hier auch Dienste in Betracht, die 
fur ihre Nutzung notwendige Software vor der Dienst- 
ausfOhrung von einem fahrzeugexternen Systemteil in 
das Fahrzeug laden. Das zerrtrale Element fur das 
Nachladen von Komponenten ist der Komponenten- 
Lader KL Er ermdglicht sowohl das Einbringen neuer 
Komponenten in den betreffenden Systemteil wie auch 
das Auslagern nicht mehr bendtigter Komponerrten. 
[0028] Die Fdhigkeit zum dynamischen Verlagern 
von Komponenten ist bei Fahrzeugsystemen ins- 
besondere aufgrund der begrenzten fahrzeugseitigen 
Rechenkapazrtaten von Interesse. So ist es zum einen 
wunschenswert, nur eine relativ geringe Rechenkapazi- 
tat im Fahrzeug vorhalten zu mussen und die Hauptlast 
der Berechnungen in der fahrzeugexternen Infrastruktur 
des Systems zu erledigen, zum anderen soil en die 
Kommuni kationskosten zur Ankopplung des fahrzeug- 
seitigen systemteils an das Netz m6glichst gering 
geharten werden. Nun sind jedoch die Kommunikations- 
kosten je nach Land Oder Region zum Teil betrachtlich 
verschieden. Berucksichtigt man die Mobilitat von Fahr- 



zeugen, so kann sich diese Randbedingung sogar wah- 
rend einer Fahrt andern. Wird zudem noch die absolute 
Verfugbarkeit eines Kommunikationsdienstes in das 
Kostenmodell aufgenommen, so ergibt sich ein Opti- 

5 mierungsproblem, das mit einer dynamischen Ver- 
schiebbarkeit von Komponenten zwischen den 
Systemteilen deutiich besser lOsbar ist als mit einer 
starren Struktur und Verteilung der Komponenten. Der 
Korrfigurations-Manager KM dient nundazu, eine jewei- 

70 lige verlagerte Komponente in ihre neue Urngebung 
"hineinzukonfigurieren" und die bereits vorhandenen 
Komponenten uber die neu in den betreffenden 
Systemteil hinzugekommene Komponente zu "informie- 
ren", d.h. deren Konfiguration daran anzupassen. Zu 

is diesem Zweck hat der Konfigurations-Manager KM uber 
die Konfigurations-Schnittstellen Zugriff auf die einzel- 
nen Komponenten des betreffenden Systemteils. Der 
Korrfigurations-Manager KM weiQ, welche Komponen- 
ten im System sind, uberpruft deren Konsistenz und 

20 nimmt dann die geeigneten modifizierenden Konfigura- 
tionszugriffe auf die einzelnen Komponerrten vor. 
[0029] Fig. 7 zeigt die Fdhigkeit zum dynamischen 
Verlagern einer Komponente zwischen einem Fahrzeug 
31 einerseits und fahrzeugexterner Systeminfrastruktur 

25 32 andererseits am Beispiel einer Service- Support - 
Komponente 33 anhand von drei unterschiedlichen 
Szenarien, die eine solche Komponentenverlagerung 
wunschenswert machen, siehe hierzu auch den Zert- 
schriftenaufsatz S. Hild und R Robinson, "Mobilizing 

30 Applications", IEEE Personal Communications, 4, Nr. 5, 
1997, Seite 26. Ausgegangen wird hierbei von einem 
erwerterten Client/Server-Mod ell. bei dem zwischen 
einer Prasentations-Manager-Komponente 34 im Fahr- 
zeug 31 als Client und einer Server-Komponente 35 auf 

35 der Infrastrukturseite noch als Server die Service-Sup- > 
port-Komponente 33 zwischengeschattet ist, die in 
reduztertem Ma8 gewisse Server-Funktionen statt der 
infrastrukturseitigen Server-Komponente 35 ausfuhren 
kann. 

40 [0030] Im Fall hoher Kommunikationskosten zwi- 
schen Fahrzeug 31 und Infrastruktur 32 wird die im 
obersten Teilbild von Fig. 7 dargestellte LGsung 
gewahlt, bei der die Service-Support-Komponente 33 
im Fahrzeug 31 positiontert ist, so daG sie ihre Kommu- 

45 nikation mit dem Prasentations-Manager 34 fahrzeugin- 
tern abwickeln kann und ein hoher Anteil der 
Berechnungen im Fahrzeug 31 durchgefuhrt wird, was 
die Komrnunikation mit der Infrastruktur 32 minimal halt 
Oder zeitweise ganz vermeidet. In diesem Fall bildet das 

so Fahrzeug einen "Thick Mobile Host", der eine reduzierte 
Version der infrastrukturseitigen Servicer-Komponente 
35 in Form der Service-Support-Komponente 33 ent- 
hait. 

[0031] Ist der Aufwand fur die Komrnunikation zwi- 
55 schen Fahrzeug 31 und Infrastruktur 32 hingegen ver- 
gleichsweise gering, ist es gunstig, die in Fig. 7 im 
mittleren Teilbild gezeigte LGsung zu wahlen, bei der die 
Service-Support-Komponente 33 in der Infrastruktur 32 
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angeordnet ist und dort die Vorteile der grdBeren 
Rechenkapazitat und die Verfugbarkeit weiterer, im 
Datennetz befindlicher Ressourcen, wie z.B. aktuelle 
Verkehrsdaten, nutzen kann. In diesem Fall bildet das 
Fahrzeug einen Thin Mobile Host". 
[0032] Die dynamische Verlagerung von Kompo- 
nenten, wie hier der Service-Support-Komponente 33, 
dierrt nun dazu, eine bleibende Beschrankung auf die 
eine oder die andere dieser beiden erwahnten LOsun- 
gen zu vermeiden und stattdessen in der Lage zu sein, 
zur Systernlaufzeit die Komponenten je nach Randbe- 
dingungen zwischen den Systemteilen, hier zwischen 
der Infrastruktur 32 und dem Fahrzeug 31. hin und her 
zu verschieben, d.h. die Service-Support-Komponente 
33 wahlweise in das Fahrzeug 31 oder in die Infrastruk- 
tur 32 zu verlagern. wie mit dem unteren Teilbild von 
Fig. 7 angedeutet ist. Das Fahrzeug 31 bildet dann 
einen "komponentenbasierten Host", in den wahlweise 
Komponenten aus der Infrastruktur 32 geladen bzw. 
aus dem Komponenten in die Infrastruktur 32 ausgela- 
gert werden kdnnen. 

[0033] Diese wesentliche Eigenschaft des vorlie- 
genden Systems ist konkreter am Beispiel einer 
Sprachbedien-Anwendung in den Fig. 8a und 8b veran- 
schaulicht. Fig. 8a zeigt ein Sprachbediensystem-Steu- 
ergerat 36. das mit einem Komponentensystem, d.h. 
mit einem Komponenten-Lader, ausgerustet ist Uber 
das Steuergerat 36 erfolgt ein Zugriff auf die notwen- 
dige Hardware, d.h. einen Lautsprecher 37 und ein 
Mikrofbn 38. Auf diesem Systemteil laufen folgende 
Komponenten. Eine hardwarebezogene Komponente 
39 dierrt dem Zugriff auf das Mikrofon 38 und den Laut- 
sprecher 37. Eine erste anwendungsunterstutzende 
Komponente 40 ertthait das fur die gewunschte Sprach- 
bedienung erforderliche Vokabular, z.B. in Deutsch. 
Eine zweite anwendungsunterstutzende Komponente 
41 bildet einen Spracherkenner und Synthesizer, der 
die notwendige Spracherkennung und Sprachsynthese 
bewerksteIHgt. Eine Anwendungskomponente in Form 
eines Nachrichtenvorlesers 42 dient zur Steuerung der 
Applikation. 

[0034] Ausgehend von diesem Sprachbedien- 
Systemteil besteht ein mOgliches Szenario darin, die 
Vokabular-Komponente 40 zwecks Landeranpassung 
des Systems und damit des Fahrzeugs gegen eine sol- 
che mit einer anderen Sprache auszutauschen. Ein 
anderes Szenario kann im Fall eines Mietfahrzeugs 
darin bestehen, eine Anpassung an die jeweils von 
einem Kunden gewunschte Sprache dadurch zu reali- 
sieren, daB sich die Vokabular-Komponente mit der 
jeweiiigen Sprache uber ein MenG vom Kunden aus- 
wahlen laBt, worauf hin die betreffende Komponente 
nachgeladen wird. Nach Ruckgabe des Mietfahrzeugs 
wird die nachgeladene Komponente dann wieder ent- 
fernt 

[0035] Ein komplexerer Fall einer Komponentenver- 
schiebung fur den Systemteil von Fig. 8a ist in Fig. 8b 
dargestellt. Dieser Fall betrifft eine Auslagerung m6g- 



lichst vieler Komponenten des Sprachbedien-System- 
teils vom Fahrzeug 36 in fahrzeugexterne Systemteile, 
d.h. in die fahrzeugexterne Infrastruktur 43 des 
Gesamtsystems. Speziell kdnnen durch die Fahigkeit 
5 des voriiegenden Systems zur dynamischen Kompo- 
nentenverlagerung die Anwendungs-Komponerrte 42 
und die beiden anwendungsunterstutzenden Kompo- 
nenten 40, 41 in die Infrastruktur 43 verlegt werden, wo 
sie aufgrund der hdheren Rechnerleistung effizienter 
w arbeiten kOnnen. Im Fahrzeug 36 verbleibt die fahrzeu- 
geratenahe Interface- Komponente 40. Die Daten wer- 
den uber die fahrzeugseitig verWiebene Schnittstellen- 
Komponente 40 und eine drahtlose Verbindung 44 zwi- 
schen Fahrzeug 36 und fahrzeugexterner Infrastruktur 
is 43 Obertragen. Abhangig von der vorhandenen drahtlo- 
sen Kommunikation, insbesondere ihrer Verfugbarkeit 
und ihren Kosten, kann auf diese Weise ein optimaler 
KompromiB fur die Verteilung der Komponenten 39 bis 
42 des Sprachbediensystems zwischen Fahrzeug 36 
20 und fahrzeugexterner Infrastruktur 43 gewahlt werden. 
[0036] Je nach Anforderungen an fahrzeugbezo- 
gene Dienste, wie Telematik-Dienste, ist beim voriie- 
genden verteirten Fahrzeuginformationsverarbeitungs- 
und Fahrzeugsteuersystem eine bestimmte Basis- 
25 menge von Komponenten in Fahrzeugen und in der 
Infrastruktur vorhanden, die Dienste wie beispielsweise 
"ZeiT, -Ort/Position" oder "Map-Matching" anbieten. 
Diese Basisdienste kGnnen dann von mehreren ande- 
ren Diensten verwendet werden. So kann beispiels- 
30 weise die Ortsinformation sowohl von einem 
Navigationsdienst genutzt wie auch von einem Pannen- 
hilfsdienst dazu verwendet werden, die aktuelle Fahr- 
zeugposition an die Pannenhelfer weiterzugeben. 
Dienstanbieter mussen solche Basisteile des Systems 
35 nicht wiederholt entwerfen, sondern kdnnen auf die vor- 
handenen Basiskomponenten aufsetzen. Mit Hilfe der 
voriiegenden komponentenbasierten Systemarchitektur 
kOnnen neue Dienste auf der Basis existierender Kom- 
ponenten auf zwei von der Systemarchitektur unter- 
40 stutzte Arten realisiert werden, und zwar nach einem 
schnittstellenbasierten oder einem ereignisgesteuerten 
Dienstmodell. 

[0037] Beim schnittstellenbasierten Modell wird 
davon ausgegangen, daB die existierenden Komponen- 
45 ten und ihre unter Umstanden umfangreichen Dienste- 
Schnittstellen mit alien notwendigen Methoden bekanrrt 
sind. Ein neuer Dienst kann dann einfach durch die Ver- 
wendung der existierenden Funktionen erstellt werden. 
Voraussetzung ist, daB das notwendige Wissen uber 
so die prinzipielle Existenz der Konponente und Ober 
der en genauen Dienstumfang erhalten wird. 
[0038] Fig. 9 zeigt ein Navigations-Teilsystem, das 
auf einem solchen schnittstellertosierten Modell aufge- 
baut ist Dabei greift eine Komponente "Navigations- 
55 dienst" 45 auf die Dienste anderer Komponenten zu, 
wie auf eine "Mapping w -Komponente 46, eine "Routing"- 
Kbmponente 47. eine Raddrehzahlerfassungs-Konpo- 
nente 48, eine Prasentations-Manager-Komponente 49 



15 EP 1033 691 A2 



16 



etc.. urn ihren Dienst gegenuber dem Anwender zu 
erbringen. Bei der Programmierung der Navigations- 
dienst-Komponente 45 mussen die Schnittstellen der 
verwendeten Komponenten bekannt sein. 
[0039] Fig. 10 zeigt den Fall eines ereignisgesteu- 
erten Modells, das durch Verwenden einer "Shared- 
Space"-Komponente 50 realisiert ist, die einen server- 
basierten, von mehreren beteiligten Komponenten 
gemeinsam genutzten Datenspeicher darstellt, in den 
die beteiligten Komponenten bestimmte interessie- 
rende Werte/Objekte einschreiben kOnnen, wie dies in 
Fig. 10 fur eine Kalenderanwendungskomponente 51 
und eine weitere Anwendungskomponente 52 darge- 
stellt ist. Des weiteren kOnnen sich die beteiligten Kom- 
ponenten bei dieser " Shared-Space"- Komponente 50, 
die somit als eine Datenhaltungs-Kbmponente fungiert, 
registrieren lassen, um im Fall eines neu auftretenden 
Wertes/Objektes, der fur sie relevant ist, inforrniert zu 
werden, als sogenannte "event triggered notif cation" 
bezeichnet. 

[0040] Ansatze dieser Art verschieben das oben 
angesprochene Problem des Wissens uber die Exi- 
stenz von Komponenten auf eine hShere Ebene, indem 
die Kommunikation zwischen Komponenten immer uber 
die "Share-Space"-Komponente 50 stattfindet. die mit 
einer sehr kleinen API realisiert werden kann und 
jeder Komponente bekannt ist. Die Komponenten 
mussen sich lediglich uber die Inhatte einigen, die 
in die "Shared-Space"-Komponente 50 geschrieben 
werden. Sdche Ansatze sind z.B. unter den Bezeich- 
nungen "Linda Space", siehe Internet-Seite 
"http://www.cs.yale. edu/HTML^ 
ml" und "Java Spaces", Sun Microsystems, 
[0041] Internet-Seite http7/java.sun.com/pro- 
ducts/javaspaces/specs" in der allgemeinen EDVgeiau- 
fig. 

[0042] Im Beispiel von Fig. 10 liefert die Kalender- 
Anwendung 51 Neueintrage 53 in die Datenhaltungs- 
Komponente 50. Interessiert sich eine andere Anwen- 
dung 52 fur derartige Daten, erhait sie die betreffende 
Dateninformation 54 von der Datenhaltungs- Kompo- 
nente 50, wenn sie bei ihr hierfur regtstriert ist. Die 
andere Anwendung 52 kann daraus neue Daten 55 
generieren und den ubrigen Komponenten zur Verfu- 
gung stellen, indem sie diese in die Datenhaltungs- 
Komponente 50 schreibt. Interessiert sich die Kalender- 
Anwendung 52 fur diese neuen Daten 55. kann sie die 
betreffende Information 56 von der Datenhartungs- 
Komponente 50 erhalten. woraufhin der Datenaus- 
tauschkreislauf wteder von vorne beginnen kann. 
[0043] Der Vorteii dieses Modells besteht in der 
voneinander unabhangigen Programmierung der Kom- 
ponenten und dem geringen Umfang der "Shared- 
Space"- API. AuBerdem kdnnen neue Komponenten 
problerrdos in das System integriert werden und sofort 
aktiv zur Erbringung von Mehrwertdiensten bertragen. 
Applikationen mussen hierzu "kooperativ" geschrieben 
werden. d.h. so. daB sie relevante Information auch tat- 



sachlich indie "Shared-Space"- Komponente schreiben. 
In der "Shared-Space"-Komponente sind geeignete 
Mechanismen, wie Zeituberwachung, Transaktions- 
modelle etc., implementiert, die das Auftreten oszillie- 

5 render Effekte zwischen Komponenten beim 
wechselseitigen Einschreiben neuer Werte in die 
"Shared-Space"-Komponente unterbinden. Vorteilhaft 
kann eine kombinierte Realisierung von zum Teil 
schnittstellenbasierter und zum Teil ereignisgesteuerter 

10 Modellierung in Abhangigkeit von den jeweiligen 
Anwendungen sein. So ist z.B. bei der Verarbeitung 
eines Motordrehzahlwertes, der standig in Abstanden 
von wenigen Millisekunden zur Verfugung steht, ein 
ereignisgesteuertes Model), bei dem jeder neue Dreh- 

75 zahlwert in die "Shared- Space" -Komponente geschrie- 
ben und alle potentiellen Abnehmerkomponenten 
daruber benachrichtigt werden, wenig sinnvoll, so daB 
hierfur eine schnrttstellenbasierte Modellierung zu favo- 
risieren ist 

20 [0044] Eine plattformunabhangige Realisierung des 
vorliegenden verteilten Fahrzeuginformationsverarbei- 
tungs- und Fahrzeugsteuersystems ist, wie schon 
erwahrtt, z.B. durch Wahl der Entwicklungs- und Imple- 
mentierungsumgebung "Java" m6glich, da diese bereits 

25 an vielen Stellen eine objektorientierte Implementie- 
rung von Komponenten direkt unterstutzt. wobei als 
Komponenten-Lader, wie ebenfalls oben erwahnt. z.B. 
der in Java implementierte ChaiServer von Hewlett- 
Packard genutzt werden kann. Um einen Zugrrff auf die 

30 Systemhardware zu ermGglichen, der von Java nicht 
standardmaBig vorgesehen ist, werden zusatzliche 
Klassen in das System gebracht, die ebenfalls uber das 
Systemkonfigurationsmanagement uberwacht und nur 
bei Bedarf in das Fahrzeug geladen werden. Das Her- 

35 ausnehmen einer Komponente, um die betreffende 
Ressource wieder freizumachen, wird im Rahmen der 
dynamischen Komponentenverlagerung ebenfalls 
durch den ChaiServer unterstutzt. Durch die Implemen- 
tierung in Java wird eine hohe Plattformunabhangigkeit 

40 erreicht. Komponenten kOnnen in einer Komponertten- 
datenbank in der fahrzeugexternen Infrastruktur gespei- 
chert und bei Bedarf in die entsprechenden Systeme 
geladen werden. Die Komponenten sind vorzugsweise 
unter objektorientierten Gesichtspunkten modelliert und 

45 implementiert und ahneln dabei den Java "Servlets", die 
dazu verwendet werden, die Funktionalitat der Server- 
seite auf einfache Art zu erweitern, siehe fur die allge- 
meine EDV die Verdffentlichung "Servlets" von Sun 
Microsystems. Internet-Seite "http://java.sun.com/pro- 

so ducts/javaserver/servlets". Die Kommunikation zwi- 
schen den Komponenten basiert auf der Java-RMI. 
[0045] Methoden von Komponenten. die im Kontext 
des Chai Servers laufen. werden mittels HTTP aufgeru- 
fen, siehe J. Morgan. "The HE HAW Invocation Model. 

55 Broadband Information Systems. Hewlett-Packard. Palo 
Alto, 1997. Die Verwendung von HTTP hat den Vorteii, 
daB es fast uberall unterstutzt wird und auch "Firewalls" 
ubertragbar sind. Durch die oben erwahnte Adressie- 
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rung und Aufrufsyrrtax mittels "uniform resource locator 
(URL) wind die gewunschte Ortstransparenz erreicht 
[0046] Fig. 1 1 zeigt einen diesbezuglichen Anwen- 
dungsfall mit einer Baspielkomponente 57, die auf einer 
Fahrzeug-Maschine 58 ausgefuhrt wird. Die Kompo- s 
nerrte 57 stellt eine Methode "Foo" zur Verfugung, die 
mit einem String-Argument aufgerufen wird. Das Ergeb- 
nis der Methode kann ein HTML-Dokument sein. Die 
HTTP-Aufrufsyntax beinhaltet dann bei einem Auf ruf 59 
durch eine andere Komponente 60 die Adresse der io 
Fahrzeug-Maschine 58, die Bezeichnung der Beispiel- 
komponente 57 und die Angabe der Methode "Foo" mit 
"html" -Charakterisierung. 

[0047] Die obige Beschreibung eines vorteilhaften 
Ausfuhrungsbeispiels und mOglicher Modifikationen is 
hiervon macht deutlich, daB das erfindungsgemaGe 
verteilte Fahrzeuginformationsverarbeitungs- und Fahr- 
zeugsteuersystem eine flexible und dynamisch anpaB- 
bare Umgebung fur fahrzeugbezogene Dienstan- 
wendungen bereitstellt. Die objektorientierte Modellie- 20 
rung und einfache Kombinierbarkeit der Korrponenten 
durch ihre einheitlichen Schnittstellen erlauben einen 
raschen und einfachen Aufbau neuer Dienste. Durch 
die zur Systemlaufzeit mSgliche Verlagerung von Kom- 
ponenten zwischen Fahrzeug und fahrzeugexterner 25 
Infrastruktur kann sich das System optimal den sich 
dynamisch andernden Randbedingungen in der Infra- 
struktur anpassen. 

Patentanspruche 30 

1. Verteiltes Fahrzeuginfortnationsverarbeitungs- und 
Fahrzeugsteuersystem mit 

wenigstens einem fahrzeugseitigen, ersten 35 
Systemteil (1a) und wenigstens einem weite- 
ren. zweiten Systemteil (2a, 3a), die jeweils zur 
Ausf Qhrung einer oder mehrerer fahrzeugbezo- 
gener Anwendungsfunktion eingerichtet sind 
und miteinander uber ein Datenubertragungs- 40 
netzwerk (4) kommunizieren, 
dadurch gekennzeichnet, daB 
- die Systemteile (1a, 2a, 3a) einen komponen- 
tenbasierten Aufbau aus verschiedenen, mit- 
einander kommunizierenden Korrponenten 45 
(AK 1t ...) zur AusfOhrung unterschiedlicher 
Funktionen besitzen, bei dem jede Kompo- 
nente eine Funktionsaufruf-Schnittsteile (5a), 
Ober welche die von der Komponente ausge- 
fQhrte Funktion von anderen Komponenten so 
desselben oder eines anderen Systemteils auf- 
rufbar ist, und eine Konfigurations-Schnittstelle 
(5b) aufweist, Ober die ihre Konfiguration varia- 
bel festiegbar ist, wobei eine Konfigurations- 
managereinheit (KM) vorgesehen ist welche ss 
die Komponenten Qber ihre Konfigurations- 
Schnittstelle in Abhfingigkeit davon konfigu- 
riert. welche anderen Komponenten im System 



vorhanden sind. 

2. Verteiltes System nach Anspruch 1 , weiter 
gekennzeichnet durch 

einen den Komponenten des jeweiligen Systemteils 
zugeordneten Komponenten-Lader (KL). 

3. Verteiltes System nach Anpsruch 1 oder 2, weiter 
dadurch gekennzeichnet, daB 

die Komponenten eines jeweiligen Systemteils 
funktionsorientiert hierarchisch in eine Anwen- 
dungs-Komponentenschicht, eine Schnittstellen- 
Kbmponentenschicht und eine zwischenliegende 
Aggregations -Komponentenschicht gruppiert sind. 

4. Verteiltes System nach einem der AnsprOche 1 bis 

3, weiter 

gekennzeichnet durch 

Mittel zum dynamischen Velagern einer oder meh- 
rerer Komponenten (33) wahrend der Systemlauf- 
zeit zwischen verschiedenen Systemteilen (31, 32). 

5. Verteiltes System nach einem der Ansprfiche 1 bis 

4, weiter 

dadurch gekennzeichnet, daB 
je zwei Anwendungs-Komponenten nach einem 
schnittstellenbasierten Modell direkt oder nach 
einem ereignisgesteuerten Modell uber eine Daten- 
haltungs-Komponente (50) kommunizieren. 
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komponentenbasierten Aufbau aus verschiedenen, mit- 
einander kommunizierenden Komponenten zur Ausfuh- 
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anderen Komponenten im System vorhanden sind. 

Verwendung z.B. fur ein verteiltes Informationsver- 
arbeitungs- und Steuersystem fur Automobile. 
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